June 15, 2019
PoC Pipeline AppSec
Mise en place d'un pipeline AppSec dans le but d'automatiser les tests de securités dans la chaine DevOps
Objectif du projet
Au fil des ans, les conférences, les exposés, les présentations et la documentation accessibles au public ont prouvé la viabilité d'un modèle et ont fait l'objet d'un consensus en vue de son adoption. L'OWASP a publié en octobre 2015 un modèle de référence pour un pipeline AppSec.
Le template de référence défini par OWASP répond à toutes les exigences d'un pipeline AppSec moderne conçu pour l'amélioration itérative et avec la capacité d'évoluer organiquement dans le temps.
L'objectif d'un AppSec Pipeline est de fournir un processus cohérent à partir de l'équipe de sécurité des applications et de l'électorat qui est généralement composé de développeurs, d'assurance qualité, de gestionnaires de produits et d'intervenants principaux.
Tout au long du processus, chaque activité a des états bien définis. Le pipeline s'appuie fortement sur l'automatisation pour les tâches répétitives afin d'optimiser la ou les ressources critiques.
Fonctionnement global
Le pippeline est construit sur quatre zones distinctes. La première est le "processus d'admission" ou la "première impression" (Intake). C’est là que les clients demandent des services AppSec tels que des évaluations dynamiques, statiques ou manuelles de l'équipe de cybersecurité. Le processus d'admission consiste en un dépôt de requête qu'un demandeur choisira à partir d'une liste de possibilités ou fournira d’avantages de détails si nécessaire.
La deuxième partie est le "triage". Ici on détermine l'application des services demandés. Une demande d'application peut comporter un balayage automatisé.
La troisième partie est le "test" qui est le coeur du pipeline. C'est ici que tous les outils AppSec sont automatisés, que les résultats sont introduits dans un référentiel central et examinés pour détecter les faux positifs.
Enfin, l'extrémité du pipeline est "livrer" (Deliver) où les résultats sont distribués au client. Ce retour peut varier d'une organisation à l'autre, mais la plupart des pipelines s'intègrent à un système de suivi des défauts et produiront des mesures sommaires et des rapports à l'intention de la haute direction. Dans le cadre du projet, il a été décidé de faire ce retour sur un service de Ticketing. (Jira).
Le travail se concentre principalement sur l’implémentation de deux éléments du pipeline. Les Application Vulnerability Correlators (AVC), modélisés par les outils de Security orchestration et vulnerability repository sur le schéma. Le deuxième élément est la partie threat modeling.
Raison d'être des AVC
Les solutions de correction de la vulnérabilité des applications (AVC) visent à aider les équipes de développement et de sécurité à hiérarchiser leurs efforts pour résoudre les problèmes de sécurité. Lorsqu'ils effectuent des tests de sécurité d'applications statiques (SAST)* et dynamiques (DAST),* les scanners de sécurité signalent par nature des résultats faux positifs et incomplets, ce qui rend difficile pour les équipes de développement de concentrer leurs efforts de correction au bon endroit. Afin d'augmenter la précision, plusieurs scanners doivent être exécutés avec la même base de code (SAST) et la même application déployée (DAST). Cependant, le traitement manuel de tous les résultats rapportés par les scanners est une tâche longue et sujette aux erreurs, qui n'évolue pas et crée des goulots d'étranglement dans les processus DevOps.
Pour résoudre ce problème, les solutions AVC offrent deux fonctionnalités principales: la déduplication et la corrélation des résultats des différents scanners de sécurité.
La déduplication réduit le nombre de résultats et augmente leur précision ; en regroupant les résultats avec les résultats d'un scanner donné, et entre les résultats de plusieurs scanners, la confiance dans les résultats est accrue et la probabilité d'un faux positif diminue.
La corrélation aide à établir les priorités ; en faisant correspondre les résultats du SAST aux résultats du DAST, il est prouvé que le code est vulnérable aux attaques et doit donc être corrigé en priorité, par rapport à une exploitation théorique.
Enfin, associés à la modélisation des threads, les résultats sont triés et pondérés pour refléter l'acceptation du risque d'IDEMIA sur l'application analysée. Certains d'entre eux peuvent ne pas régler les problèmes, ce qui reflète les risques acceptés. D'autres peuvent devenir des problèmes critiques, reflétant des risques critiques nécessitant une réduction et nécessitant une attention immédiate. Pour mieux comprendre la gestion des risques dans le cycle de vie du développement logiciel, continuez à lire avec la modélisation des threads.
Raison d'être du Threat Modeling
Le concept du threat modeling est d’avoir une approche significative et fondée sur les risques en matière de sécurité. Cette partie répond aux questions : qu’est ce qui peut mal tourner dans mon cas ? Et comment puis-je éviter cela. C’est donc une évaluation du risque d’un projet, accompagnée de contre-mesures. Comme les autres parties du pipeline AppSec, cette partie s’intègre avec le flux de travail des développeur en leur faisant des retours et en organisant une planification des taches sur notre support de ticketing.